home *** CD-ROM | disk | FTP | other *** search
/ Aminet 22 / Aminet 22 (1997)(GTI - Schatztruhe)[!][Dec 1997].iso / Aminet / util / boot / AllocP32.readme < prev    next >
Text File  |  1997-11-02  |  10KB  |  252 lines
  1. Short:    AllocP32 - BetterAlloc (AllocMem patch for PPC) V2.01
  2. Author:   thor@math.tu-berlin.de 
  3. Uploader: thor@math.tu-berlin.de
  4. Version:  2.01
  5. Type:     util/boot
  6.  
  7. (with the friendly permission of the original author, Andreas Kleinert)
  8.  
  9. _____________________________________________________________________________
  10.  
  11. New in release 2.01:
  12.  
  13.     - Added a workarount for stupid "SaferPatches" clones.
  14.  
  15. _____________________________________________________________________________
  16.  
  17. New in release 2.00:
  18.  
  19.     - Rewritten in assembly language, much shorter file
  20.     - Tries a partial flush first, instead of removing
  21.       all libraries on failure.
  22.     - Removed unnecessary AllocVec patch since it calls
  23.       AllocMem anyways.
  24.     - Added workarounds for bugs in the layers.lib
  25.  
  26. _____________________________________________________________________________
  27.  
  28. AllocP32 will be part of a major memory defragmentizer project still to be
  29. published, called PoolMem. Please stay tuned!
  30. _____________________________________________________________________________
  31.  
  32. WARNING: THIS PATCH ISN'T WITHOUT QUIRKS! READ THIS FILE CAREFULLY BEFORE
  33. INSTALLING ALLOCP32. REALLY, I MEAN IT!
  34. _____________________________________________________________________________
  35.  
  36. AllocP32 is identical to AllocP EXCEPT that it allocates memory in 32 byte
  37. wide blocks to avoid conflicts between PPC and MC68K microprocessors. If
  38. you don't have a PPC board, this patch is most likely unnecessary and will
  39. only slow down your computer and waste memory. Use AllocP instead.
  40.  
  41. This program is still in an "experimental" phase, even though it has been
  42. tested now. No guarantee that this works with a PPC board, I don't have
  43. one for testing! (However, it's welcome as a gift.... ;-)
  44. _____________________________________________________________________________
  45.  
  46.  Sometimes programs fail with a "not enough memory" error,
  47.  but after calling "avail flush" the same operation does
  48.  succeed without problems.
  49.  
  50.  
  51.  If AllocMem routine in the ROMs did not find enough memory,
  52.  it tries to flush disk based libraries and devices and,
  53.  afterwards, tries again to reallocate the memory.
  54.  However, due to a design flaw of the AllocMem() routine,
  55.  this memory flushing does not have the desired result some-
  56.  times - even though the libraries have been informed to
  57.  remove themselves, the memory is not available directly
  58.  afterwards. The AllocMem() call will fail anyways, EVEN THOUGH 
  59.  the requiested memory will be available immediatly after completion 
  60.  of AllocMem().
  61.  The reasons for this strange behaiviour are rather technical 
  62.  and explained below, for the interested user.
  63.  
  64.  
  65.  This patch does ensure that AllocMem/AllocVec won't
  66.  fail unless there's really no memory available, even
  67.  by flushing. It does ALSO, and in addition to AllocP,
  68.  ensure that the allocated memory is contained in 
  69.  32 byte memory blocks and not on boundaries of these
  70.  blocks, so match in one cache line of either the PPC
  71.  or the MC68K microprocessor, not in both. 
  72.  This avoids that parts of the allocated memory is in 
  73.  different caches of the two CPUs and not up-to-date. 
  74.  The patch DOES NOT ensure that the memory is 32 byte 
  75.  aligned! (The current implemenation returns always 
  76.  memory eight bytes on top of a 32 byte boundary, 
  77.  but don't take this for sure!)
  78.  
  79.  The patch does NOT apply to structures allocated by the
  80.  layer library so take care! The reason is a design flaw
  81.  (avoiding to call this a serious bug) in the layers
  82.  library, which causes also some trouble for MungWall
  83.  and MemSniff. See below for what this bug is about.
  84.  
  85. WARNING: Due to this workaround of the layers.libary bug,
  86.  it is currently NOT allowed to install an AllocMem()
  87.  patch ON TOP of this one or it will CRASH! If a second
  88.  patch of AllocMem is unavoidable, run AllocP32 LAST!
  89.  To find out which patches are installed in your system,
  90.  get the "SaferPatches" package from my home page at
  91.  
  92.  http://www.tu-berlin.de/~thor/thor/index.html
  93.  
  94.  or from the AmiNet.
  95.  
  96.  Because of the memory alignment, AllocP32 must allocate
  97.  more memory than requested and will "round up" the memory
  98.  size to fit entirely in 32 byte blocks. This DOES, of course,
  99.  waste memory! Don't use this patch without good reason!
  100.  (good reason = a PPC board!)
  101.  
  102.  
  103.  Note:  Works now for all operating systems and all CPUs,
  104.     is no longer restricted to V37 or MC'20.
  105.     Does not require a PPC, but if you don't have one,
  106.     try AllocP instead - it's much less memory consuming.
  107.  
  108.  Usage:  Try starting in the Shell/CLI.
  109.          If it does run stable, copy it into
  110.          your C: directory and add it
  111.          somewhere into your s:user-startup
  112.  
  113.                 AllocP32
  114.  
  115.  You use this patch at your own risk.
  116.  No guarantee for anything.
  117.  Source code in assembly language included, requires the DevPac assembler
  118.  and my macro package at dev/asm/DvPkMacros.lha in the AmiNet.
  119.  
  120.  
  121.  All mentioned trademarks are subject to their owners.
  122. _____________________________________________________________________________
  123.  
  124. The design flaw in AllocMem():
  125.  
  126.     When looking closely at the ROM routine of AllocMem(), you'll
  127.     notice that a memory flush is TRIED if the first allocation
  128.     failed. 
  129.     Why does AllocMem then fail, even though if enough memory
  130.     is available?
  131.  
  132.     Consider the following situation:
  133.     A library has launched a sub-task for control of some of its
  134.     features. This sub-task could be used for disk I-O, for example.
  135.  
  136.     If this hypothetical library has to be expunged, it can't do
  137.     this on its own because this will release memory of the sub-task
  138.     which is still running. This sub-task must be informed somehow
  139.     that its memory must go. While this is in principle simple to do -
  140.     just send a message to the sub task - the library can't wait for
  141.     an answer of the sub-task because this would brake the Forbid()
  142.     state, which is illegal at this point of the operation.
  143.     The only solution for the library is to leave the memory flush
  144.     to the sub task and to return to the low-memory handler of exec
  145.     WITHOUT trying to remove itself - leaving this to its sub-task.
  146.     
  147.     On the other hand, since multitasking is still forbidden, there
  148.     is NO chance that this subtask will actually get a chance to 
  149.     remove the library, leaving it in memory and causing the 
  150.     allocation failure. EVEN THOUGH the library was informed to
  151.     get removed, there is no chance of doing this while flushing.
  152.  
  153.     However, as soon as exec leaves the AllocMem routine, multi-
  154.     tasking will be turned on again, thus causing a task switch to
  155.     the subtask and NOW causing the removal of the library - to late
  156.     to have any effect.
  157.  
  158.     AllocP tries to avoid this situation by calling AllocMem a
  159.     second time.
  160.  
  161. _____________________________________________________________________________
  162.  
  163. The bug in the layers.library:
  164.  
  165.     The layers.library allocates memory for tempory region information
  166.     in big chunks and cuts this memory apart in smaller pieces, freeing
  167.     the snippets individually. This is according to the RKRM standards
  168.     ILLEGAL and has caused a lot of problems (including crashes of
  169.     earlier versions of AllocP32) not only for AllocP32. 
  170.     Please DO NOT share layers.library structures between different CPUs
  171.     until this has found a solution in a bugfixed OS version. If this
  172.     can't be avoided, flush the data caches!
  173.  
  174. _____________________________________________________________________________
  175.  
  176.                         The THOR-Software Licence
  177.  
  178.  
  179. This License applies to the computer programs known as "AllocP32".
  180. The "Program", below, refers to such program.
  181.  
  182.  
  183. The programs and files in this distribution are freely distributable
  184. under the restrictions stated below, but are also Copyright (c)
  185. Thomas Richter.
  186.  
  187.  
  188. Distribution of the Program by a commercial organization without written
  189. permission from the author to any third party is prohibited if any payment
  190. is made in connection with such distribution, whether directly
  191. (as in payment for a copy of the Program) or indirectly (as in payment
  192. for some service related to the Program, or payment for some product
  193. or service that includes a copy of the Program "without charge";
  194. these are only examples, and not an exhaustive enumeration of prohibited
  195. activities). However, the following methods of distribution involving
  196. payment shall not in and of themselves be a violation of this restriction:
  197.  
  198.  
  199. (i) Posting the Program on a public access information storage and
  200. retrieval service for which a fee is received for retrieving information
  201. (such as an on-line service), provided that the fee is not
  202. content-dependent (i.e., the fee would be the same for retrieving the same
  203. volume of information consisting of random data).
  204.  
  205.  
  206.  
  207. (ii) Distributing the Program on a CD-ROM, provided that the files
  208. containing the Program are reproduced entirely and verbatim on such
  209. CD-ROM, and provided further that all information on such CD-ROM be
  210. redistributable for non-commercial purposes without charge.
  211.  
  212.  
  213.  
  214. Everything in this distribution must be kept together, in original
  215. and unmodified form.
  216.  
  217.  
  218.  
  219.  
  220. Limitations.
  221.  
  222. THE PROGRAM IS PROVIDED TO YOU "AS IS," WITHOUT WARRANTY. THERE IS NO
  223. WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
  224. LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  225. PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
  226. RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
  227. THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
  228. SERVICING, REPAIR OR CORRECTION.
  229.  
  230.  
  231.  
  232. IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE ALL FILES CONTAINED IN
  233. THIS ARCHIVE.
  234.  
  235. _____________________________________________________________________________
  236.  
  237. Thomas,
  238.  
  239.     October 1997
  240.  
  241.  
  242. ============================= Archive contents =============================
  243.  
  244. Original  Packed Ratio    Date     Time    Name
  245. -------- ------- ----- --------- --------  -------------
  246.      592     455 23.1% 14-Oct-97 19:41:34 +AllocP32
  247.    12990    3492 73.1% 14-Oct-97 19:41:20 +AllocP32.asm
  248.     9618    4164 56.7% 14-Oct-97 19:43:48 +AllocP32.readme
  249.      856     377 55.9% 11-Oct-97 12:00:42 +AllocP32.readme.info
  250. -------- ------- ----- --------- --------
  251.    24056    8488 64.7% 16-Oct-97 04:01:52   4 files
  252.